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BANDWIDTH MANAGEMENT TECHNIQUES FOR DELIVERY OF 
INTERACTIVE PROGRAM GUIDE 



RELATED APPLICATIONS 

The present application is based on co-pending U.S. Provisional Patent 
Application Serial No. 60/178,100, filed January 26, 2000, inventors Sadik Bayrakeri and 
Donald F. Gordon, and entitled "BANDWIDTH MANAGEMENT TECHNIQUES FOR 
DELIVERY OF INTERACTIVE PROGRAM GUIDE." (Attorney Docket No. 19880- 
001600US) 

BACKGROUND OF THE INVENTION 

1 . Field of the Invention 

The invention relates to communications systems in general. More 
specifically, the invention relates to video communications systems and interactive 
program guides for video programming. 

2. Description of the Background Art 

Over the past few years, the television industry has seen a transformation 
in a variety of techniques by which its programming is distributed to consumers. Cable 
television systems are doubling or even tripling system bandwidth with the migration to 
hybrid fiber coax (HFC) cable plant. Customers unwilling to subscribe to local cable 
systems have switched in high numbers to direct broadcast satellite (DBS) systems. And, 
a variety of other approaches have been attempted focusing primarily on high bandwidth 
digital technologies, intelligent two way set top boxes, or other methods of trying to offer 
service differentiated from standard cable and over the air broadcast systems. 

With this increase in bandwidth, the number of programming choices has 
also increased. Leveraging off the availability of more intelligent set top boxes, several 
companies such as Starsight Telecast Inc. and TV Guide, Inc. have developed elaborate 
systems for providing an interactive listing of a vast array of channel offerings, expanded 
textual information about individual programs, the ability to look forward to plan 



television viewing as much as several weeks in advance, and the option of automatically 
programming a VCR to record a future broadcast of a television program. 

Unfortunately, the existing program guides have several drawbacks. They 
tend to require a significant amount of memory, some of them needing upwards of one 
5 megabyte of memory at the set top terminal (STT). They are very slow to acquire their 
current database of programming information when they are turned on for the first time or 
are subsequently restarted (e.g., a large database may be downloaded to a STT using only 
a vertical blanking interval (VBI) data insertion technique). Disadvantageously, such 
slow database acquisition may result in out of date database information or, in the case of 
10 a pay per view (PPV) or video on demand (VOD) system, limited scheduling flexibility 
for the information provider. 

The use of compression techniques to reduce the amount of data to be 
transmitted may increase the speed of transmitting program guide information. In several 
communications systems, the data to be transmitted is compressed so that the available 

1 5 transmission bandwidth is used more efficiently. For example, the Moving Pictures 
Experts Group (MPEG) has promulgated several standards relating to digital data 
delivery systems. The first, known as MPEG-1 refers to ISO/IEC standards 1 1 172 and is 
incorporated herein by reference. The second, known as MPEG-2, refers to ISO/IEC 
standards 13818 and is also incorporated herein by reference. A compressed digital video 

20 system is described in the Advanced Television Systems Committee (ATSC) digital 
television standard document A/53, and is incorporated herein by reference. 

The above-referenced standards describe data processing and manipulation 
techniques that are well suited to the compression and delivery of video, audio and other 
information using fixed or variable rate digital communications systems. In particular, 

25 the above-referenced standards, and other "MPEG- like" standards and techniques, 

compress, illustratively, video information using intra-frame coding techniques (such as 
run-length coding, Huffman coding and the like) and inter-frame coding techniques (such 
as forward and backward predictive coding, motion compensation and the like). 
Specifically, in the case of video processing systems, MPEG and MPEG-like video 

30 processing systems are characterized by prediction-based compression encoding of video 
frames with or without intra- and/or inter-frame motion compensation encoding. 



2 





However, the MPEG-1 and MPEG-2 standards have, in some instances, 



very strict elementary stream and transport stream formats, causing usage of extra 
bandwidth for certain applications. For example, if a number of interactive program guide 
(IPG) pages were created as video sequences, only limited number of pages could be 
5 encoded into a transport stream(s) at a specified bandwidth. 

Therefore, it is desirable to provide techniques for more efficiently 
utilizing a limited and finite bandwidth for transmitting program guide video sequences to 
set-top terminals. 



the finite bandwidth available for distribution of interactive program guide (IPG) video 
sequences. In this invention, novel systems and methods are introduced to provide 



bandwidth management to handle broadcast, narrowcast, pointcast, and "shared" 
pointcast streams in combination. Bandwidth management techniques in an end-to-end 
15 system play a key role in latency reduction and improving overall-efficiency of the 
interactive system. 

The present invention includes methods for managing delivery of video 
sequences for an IPG to a plurality of terminals. The methods comprise delivery by way 
of various techniques, including broadcasting, pointcasting, narrowcasting, and variants 
20 and combinations of those techniques. 



steps of: pre- allocating a broadcast bandwidth in the communications network for 
common video sequences to be transmitted by a broadcast technique; transmitting in the 
broadcast bandwidth the common video sequences to the plurality of terminals by way of 
25 the broadcast technique; receiving a request for a specific video sequence from a specific 
terminal via the communications network; allocating a demandcast bandwidth in the 
communications network for the specific video sequence; and transmitting in the 
demandcast bandwidth the specific video sequence to the specific terminal via the 
communications network. 



SUMMARY OF THE INVENTION 
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The present invention provides techniques for more efficient utilization of f 



One embodiment of the present invention is a method that includes the 



3 



BRIEF DESCRIPTION OF THE DRAWINGS 

The teachings of the present invention can be readily understood by 
considering the following detailed description in conjunction with the accompanying 
drawings. 

5 Figure 1 depicts an illustrative communications network 1 00 for 

distributing video sequences to a plurality of terminals in accordance with an embodiment 
of the present invention. 

Figure 2A is a flow chart showing a method 200 for broadcasting 
interactive program guide (IPG) pages in accordance with an embodiment of the present 
10 invention. 

Figure 2B depicts a topology 250 for broadcasting IPG pages in 
accordance with an embodiment of the present invention. 

Figure 3 A is a flow chart showing a method 300 for pointcasting IPG 
pages in accordance with an embodiment of the present invention. 

15 Figure 3B depicts a topology 350 for pointcasting IPG pages in accordance 

with an embodiment of the present invention. 

Figure 4A is a flow chart showing a push method 400 for narrowcasting 
IPG pages in accordance with an embodiment of the present invention. 

Figure 4B depicts a push topology 450 for narrowcasting IPG pages in 
20 accordance with an embodiment of the present invention. 

Figure 5 A is a flow chart showing a pull or demandcast method 500 for 
narrowcasting IPG pages in accordance with an embodiment of the present invention. 

Figure 5B depicts a pull or demandcast topology 550 for narrowcasting 
IPG pages in accordance with an embodiment of the present invention. 

25 Figure 6 A is a flow chart showing a method 600 for shared pointcasting of 

IPG pages in accordance with an embodiment of the present invention. 
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Figure 6B depicts a pull or demandcast topology 650 for shared 
pointcasting of IPG pages in accordance with an embodiment of the present invention. 

Figure 6C is a flow chart showing a method 660 of terminating (or 
continuing) shared pointcasts of IPG pages in accordance with an embodiment of the 
5 present invention. 

Figure 7 depicts a first system 700 for managing delivery of video 
sequences of an interactive program guide in accordance with an embodiment of the 
present invention. 

Figure 8 depicts a second system 800 for managing delivery of video 
10 sequences of an interactive program guide in accordance with an embodiment of the 
present invention. 

Figure 9 depicts an example of one frame taken from a video sequence that 
can be encoded using the present invention. 

DESCRIPTION OF THE SPECIFIC EMBODIMENTS 

1 5 Figure 1 depicts an illustrative communications network 1 00 for 

distributing video sequences to a plurality of terminals in accordance with an embodiment 
of the present invention. The illustrative network 100 comprises a cable distribution 
network, but other types of distribution networks may also be used. The network 100 
includes one or more head-ends 102, one or more centers for local neighborhood 

20 equipment 104, a plurality of distribution nodes 106, and a plurality of subscriber stations 
108. The local neighborhood equipment (LNE) 104 may be located, for example, at 
remote hubs of a cable distribution network. The end-user terminals 108 may comprise, 
for example, interactive set-top terminals (STT) or other devices with similar interactive 
functionalities. 

25 Figure 2A is a flow chart showing a push method 200 for broadcasting 

interactive program guide (IPG) pages in accordance with an embodiment of the present 
invention. As described below, the method 200 includes four steps. 

In a first step 202, a first set of IPG pages to be broadcast are 
predetermined. The first set of IPG pages may comprise video sequences, for example, 
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for a current time period. For instance, if the current time is 1 :07 pm, then the current 
time period may include programming from 1 :00 pm to 2:30 pm, assuming a 90 minute 
time period. 

In a second step 204, a second set of IPG pages to be broadcast are 
5 predetermined. The second set of IPG pages may comprise video sequences, for 

example, for a prime time period. Such a prime time period is a time period during which 
a large number of viewers typically watch TV programming. For example, the prime 
time period may include programming from 6:00 pm to 9:00 pm. 

In a third step 206, bandwidth to broadcast the first and second sets of IPG 
10 pages is allocated in the distribution system for that purpose. For example, as described 
below in relation to Figs. 7 and 8, a bandwidth manager (BWM) within a head-end 102 
and/or local neighborhood equipment 104 allocates within the in-band network the 
necessary bandwidth to broadcast the first and second sets of IPG pages to the set-top 
terminals (STT) 108. If the first and second sets overlap, then only the non-redundant 
15 video sequences need to be broadcast and so only enough bandwidth to broadcast the 

non-redundant video sequences needs to be allocated. Such a situation may happen, for 
example, when the current time period is within prime time. 

In a fourth step 208, the IPG pages of the first and second sets are 
broadcast to set-top terminals (STT) 108 within the broadcast range. The broadcast range 
20 may comprise all terminals 108 downstream from the head-end 102 or local 

neighborhood equipment 104. Only the non-redundant content needs to be broadcast. 
The broadcast is performed within the allocated in-band bandwidth. 

Figure 2B depicts a topology 250 for broadcasting IPG pages in 
accordance with an embodiment of the present invention. The topology 250 relates to the 
25 push method 200 of Fig. 2 A. As shown in Fig. 2B, the IPG pages are transmitted from 
the head-end (HE) 102 or local neighborhood equipment (LNE) 104 downstream within 
the illustrative communications network 100. As shown in Fig. 2B, the broadcast is 
pushed from the HE 102 or LNE 104 to the distribution nodes 106 and finally to the 
multitude of set-top terminals 108. 
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Figure 3 A is a flow chart showing a pull method 300 for pointcasting IPG 
pages in accordance with an embodiment of the present invention. As described below, 
the method 300 includes three steps. 

In a first step 302, a request for an IPG page is received from a STT 108. 
5 The request is transmitted upstream from the STT 108 to the HE 102 or LNE 104 by way 
of the communications network 100. The upstream transmission may be done via an out- 
of-band network. Alternatively, the upstream transmission may be done via an in-band 
network. Such a request may comprise, for example, a look ahead request where a user 
wishes to view programming for a time period ahead of the current time period. For a 
10 system where a set or sets of IPG pages are already being broadcast per Figs. 2 A and 2B, 
the STT 108 may first check to see whether or not the requested IPG page is already 
being broadcast before transmitting the request upstream. 

In a second step 304, bandwidth to pointcast the requested IPG page is 
allocated in the distribution system for that purpose. For example, as described below in 
15 relation to Figs. 7 and 8, a bandwidth manager (BWM) within a head-end 102 and/or 
local neighborhood equipment 104 allocates within the in-band network the necessary 
bandwidth to pointcast the requested IPG page to the requesting STT 108. If the 
requested IPG page is already being broadcast per Figs. 2A and 2B, then no additional 
bandwidth for a pointcast need be allocated. 

20 In a third step 306, the requested IPG page is pointcast to the requesting 

set-top terminal (STT) 108. The pointcast need only be received by the requesting STT 
108 and does not need to be received by other STTs 108. The pointcast is sent 
downstream from the head-end 102 or local neighborhood equipment 104 to the 
requesting STT 108. The pointcast is performed within the allocated in-band bandwidth. 

25 If the requested IPG page is already being broadcast per Figs. 2A and 2B, then the 
pointcast need not be performed. 

Figure 3B depicts a topology 350 for pointcasting IPG pages in accordance 
with an embodiment of the present invention. The topology 350 relates to the pull 
method 300 of Fig. 3 A. As shown in Fig. 3B, the request is transmitted upstream from 
30 the requesting STT 108 to the HE 102 or LNE 104 via illustrative communications 
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network 100. Subsequently, the requested IPG page is pointcast downstream from the 
HE 102 or LNE 104 to the requesting STT 108 via the network 100. 

Figure 4A is a flow chart showing a push method 400 for narrowcasting an 
IPG page (or multiple IPG pages) in accordance with an embodiment of the present 
invention. As described below, the method 400 includes three steps. 

In a first step 402, an IPG page is selected to be narrowcast to a group 452 
of terminals 108. For example, the group of terminals may be a group comprising a high 
concentration of users with a particular ethnicity or special interest, and the IPG page 
selected may comprise programming targeted to that ethnic group or special interest 
group. As another example, the group of terminals may comprise terminals 108 in a 
school campus or business, and the IPG page selected may comprise class instruction or 
other targeted material. The group 452 may include terminals 108 in one geographic area 
or terminals 108 dispersed among different geographic areas but linked, for example, via 
a network group address. 

In a second step 404, bandwidth to narrowcast the selected IPG pages is 
allocated in the distribution system for that purpose. For example, as described below in 
relation to Figs. 7 and 8, a bandwidth manager (BWM) within a head-end 102 and/or 
local neighborhood equipment 104 allocates within the in-band network the necessary 
bandwidth to narrowcast the selected IPG page to the group 452 of terminals 108. If the 
requested IPG page is already being broadcast per Figs. 2A and 2B, then no additional 
bandwidth for a narrowcast need be allocated. 

In a third step 406, the selected IPG page is narrowcast to the group of 
terminals 108. The narrowcast need only be received by terminals 108 within the group 
452 and does not need to be received by other STTs 108. The narrowcast is sent 
downstream from the head-end 102 or local neighborhood equipment 104 to the group 
452 of terminals 108. The narrowcast is performed within the allocated in-band 
bandwidth. If the requested IPG page is already being broadcast per Figs. 2A and 2B, 
then the narrowcast need not be performed. 

Figure 4B depicts a push topology 450 for narrowcasting IPG pages in 
accordance with an embodiment of the present invention. The topology 450 relates to the 
push method 400 of Fig. 4A. As shown in Fig. 4B, the IPG page is transmitted from the 
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head-end (HE) 102 or local neighborhood equipment (LNE) 104 downstream within the 
illustrative communications network 100. As shown in Fig. 4B, the narrowcast is pushed 
from the HE 102 or LNE 104 to one or more distribution nodes 106 and finally to the 
terminals 108 within the group 452. 

5 Figure 5 A is a flow chart showing a pull or demandcast method 500 for 

narrowcasting IPG pages in accordance with an embodiment of the present invention. As 
described below, the method 500 includes three steps. 

In a first step 502, a request for an IPG page is received from a requesting 
STT 552. The request is transmitted upstream from the requesting STT 552 to the HE 

10 102 or LNE 104 by way of the communications network 100. The upstream transmission 
may be done via an out-of-band network. Alternatively, the upstream transmission may 
be done via an in-band network. Such a request may comprise, for example, a look ahead 
request where a user wishes to view available special interest programming for a time 
period ahead of the current time period. For a system where a set or sets of IPG pages are 

15 already being broadcast per Figs. 2 A and 2B, the requesting STT 552 may first check to 
see whether or not the requested IPG page is already being broadcast before transmitting 
the request upstream. 

In a second step 504, bandwidth to narrowcast the requested IPG page is 
allocated in the distribution system for that purpose. For example, as described below in 

20 relation to Figs. 7 and 8, a bandwidth manager (BWM) within a head-end 102 and/or 
local neighborhood equipment 1 04 allocates within the in-band network the necessary 
bandwidth to narrowcast the requested IPG page to a group 554 of terminals which 
includes the requesting STT 552. If the requested IPG page is already being broadcast 
per Figs. 2A and 2B, then no additional bandwidth for a pointcast need be allocated. The 

25 group 554 may include terminals 108 in one geographic area or terminals 108 dispersed 
among different geographic areas but linked, for example, via a network group address. 

In a third step 506, the requested IPG page is narrowcast to the group 554 
of terminals 108. The narrowcast need only be received by terminals 108 within the group 
554 and does not need to be received by other STTs 108. The narrowcast is sent 
30 downstream from the head-end 102 or local neighborhood equipment 104 to the group 
554 of terminals 108. The narrowcast is performed within the allocated in-band 
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bandwidth. If the requested IPG page is already being broadcast per Figs. 2A and 2B, 
then the narrowcast need not be performed. 

Figure 5B depicts a pull or demandcast topology 550 for narrowcasting 
IPG pages in accordance with an embodiment of the present invention. The topology 550 
5 relates to the pull method 500 of Fig. 5 A. As shown in Fig. 5B, the request is transmitted 
upstream from the requesting STT 552 to the HE 102 or LNE 104 via illustrative 
communications network 100. Subsequently, the requested IPG page is narrowcast 
downstream from the HE 102 or LNE 104 to the group 554 which includes the requesting 
STT 108 via the network 100. 

10 Figure 6 A is a flow chart showing a method 600 for shared pointcasting of 

IPG pages in accordance with an embodiment of the present invention. As described 
below, the method 600 includes five steps. 

In a first step 602, a request for an IPG page is received from a first STT 
652. The request is transmitted upstream from the first STT 652 to the HE 102 or LNE 

15 104 by way of the communications network 100. The upstream transmission may be 

done via an out-of-band network. Alternatively, the upstream transmission may be done 
via an in-band network. Such a request may comprise, for example, a look ahead request 
where a user wishes to view programming for a time period ahead of the current time 
period. For a system where a set or sets of IPG pages are already being broadcast per 

20 Figs. 2A and 2B, the first STT 652 may first check to see whether or not the requested 
IPG page is already being broadcast before transmitting the request upstream. 

In a second step 604, a stream 656 is assigned to pointcast the requested 
IPG page is allocated in the distribution system for that purpose. For example, as 
described below in relation to Figs. 7 and 8, a bandwidth manager (BWM) within a head- 
25 end 102 and/or local neighborhood equipment 104 assigns the stream 656 to pointcast the 
requested IPG page to the first STT 652. The stream assignment may be made, for 
example, by assigning a particular value to the program identifier (PID) for the stream 
656. If the requested IPG page is already being broadcast per Figs. 2A and 2B, then the 
stream assignment need not be made. 

30 In a third step 606, the requested IPG page is pointcast to the first STT 652 

via the assigned stream 656. This may be done by transmitting packets that are identified 
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by the particular PID value and contain the video sequence of the requested IPG page. 
The pointcast need only be received by the first STT 652 and does not need to be received 
by other STTs 108. The pointcast is sent downstream from the head-end 102 or local 
neighborhood equipment 104 to the first STT 652. If the requested IPG page is already 
5 being broadcast per Figs. 2A and 2B, then the pointcast need not be performed. 

In a fourth step 608, a request for an IPG page is received from a second 
STT 654, where the IPG page requested is the same IPG page as the one requested by the 
first STT 652 in the first step 602. Like the first request, this second request is 
transmitted upstream from the second STT 654 to the HE 102 or LNE 104 by way of the 
10 communications network 100 via either an out-of-band network or via an in-band 

network. The second STT 654 may be either in the same geographic area as the first STT 
652, or the second STT 654 may be in a different geographic area as the first STT 652. 

Either way, in a fifth step 610, the identifier (e.g., PID value) for the 
stream 656 is transmitted from the HE 102 or LNE 104 to the second STT 654. This 
15 enables the next step 612 to occur without use of additional PIDs or additional network 
bandwidth. 

Finally, in a sixth step 612, the second STT 654 receives the requested IPG 
page via the same stream 656 as that which delivers the IPG page to the first STT 652. 
This may be done, for example, by setting the second STT 654 to decode and present 
20 packets that are identified by the particular PID value for the stream 656. Such packets 
are the ones which contain the video sequence of the requested IPG page. In this manner, 
"sharing" of the stream 656 occurs, changing the previously "single" pointcast to a 
"double" pointcast. 

Similarly, additional terminals 108 may "share" the pointcast by 
25 requesting the same IPG page and receiving it via the same stream 656. In this way, any 
number of terminals 108 may share the pointcast. This results in more efficient use of 
limited bandwidth. 

Figure 6B depicts a pull or demandcast topology 650 for shared 
pointcasting of IPG pages in accordance with an embodiment of the present invention. 
30 The topology 650 relates to the pointcast "sharing" method 600 of Fig. 6A. As shown in 
Fig. 6B, a request is transmitted upstream from the first STT 652 to the HE 102 or LNE 
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104 via illustrative communications network 100. In response, the requested IPG page is 
PointCast by way of a stream 656 from the HE 102 or LNE 104 to the first STT 652. 
Next, a second request for the same IPG page is transmitted upstream from the second 
STT 654 to the HE 102 or LNE 104 via the network 100. In response, the identifier for 
5 the stream 656 is transmitted from the HE 102 or LNE 104 to the second STT 654. 

Subsequently, the second STT 654 uses the identifier to receive the IPG page from that 
same stream 656. 

Figure 6C is a flow chart showing a method 660 of terminating (or 
continuing) shared pointcasts of IPG pages in accordance with an embodiment of the 
10 present invention. As described below, the method 660 includes five steps. 

In a first step 662, an STT finishes viewing a stream which transmits an 
IPG page. In the example discussed above with respect to Figs. 6A and 6B, the STT may 
be either the first STT 652 or the second STT 654. In general, the STT may be any of 
multiple terminals which are sharing the stream, or the STT may be the last terminal to be 
15 viewing a stream which was previously shared. 

In a second step 664, the HE 102 or LNE 104 is notified that the STT has 
finished viewing the stream. Such a notification occurs by the STT sending a 
communication upstream to the HE 102 or LNE 104 by way of an out-of-band or in-band 
network. 

20 In a third step 666, a determination is made as to whether or not that 

stream is still being viewed by one or more STTs. This determination is done within the 
HE 102 or LNE 104 and may be done by a bandwidth manager 728 or 828 in conjunction 
with a session manager 724 or 824. 

In a fourth step 668, if one or more STTs are still viewing that stream, then 
25 transmission of the stream by the HE 102 or LNE 104 continues. Such transmission is 

typically performed by the in-band delivery system 728 or 828 within the HE 102 or LNE 
104. 

Finally, in a fifth step 670, if no more STTs are still viewing that stream, 
then the stream is "torn down" so that it is no longer transmitted and no longer takes up 
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network bandwidth. The torn down stream is made available for reassignment to reuse 
the bandwidth to transmit a different pointcast, narrowcast, or broadcast. 

Figure 7 depicts a first system 700 for managing delivery of video 
sequences of an interactive program guide in accordance with an embodiment of the 
present invention. The first system 700 includes a key manager 702 5 a 
subscription/billing manager 704, an IPG generator 706, and a head-end 102. 

The head-end 102 is coupled to a multitude of STTs 108 by way of both an 
in-band network and an out-of-band (OOB) network. The head-end 1 02 includes various 
components which are coupled together and interact with each other. The head-end 102 
illustrated includes an advertising/html content source 708, an IPG content source 709, a 
compositor 710, an encoder 712, a processor 714, a multiplexor 716, an encryptor 718, an 
in-band delivery system 720, a controller 722, a session manager 724, an access manager 
726, a bandwidth manager 728, and out-of-band (OOB) equipment 730. 

Figure 8 depicts a second system 800 for managing delivery of video 
sequences of an interactive program guide in accordance with an embodiment of the 
present invention. The second system 800 includes the components of the first system 
700. In addition, the second system 800 includes local neighborhood equipment 104 and 
a video-on-demand (VOD) server 802. 

The LNE 104 is coupled to the HE 102 by way of an in-band network and 
an OOB messaging system. The LNE 104 is also coupled to a multitude of STTs 108 by 
way of a local in-band network. The LNE 104 includes various components which are 
coupled together and interact with each other. The type of components in the LNE 104 
are typically a subset of the type of components in the HE 102. The LNE 104 illustrated 
includes a processor 814, a multiplexor 816, an encryptor 818, a local delivery system 
820, a controller 822, a session manager (SM) 824, an access manager (AM) 826, and a 
bandwidth manager (BWM) 828. 

The first and second systems 700 and 800 described above are illustrative 
systems which may be used to implement the present invention. They are not meant to 
limit the present invention to those specific embodiments. 
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Figure 9 depicts an example of one frame taken from a video sequence of 
an IPG page in accordance with the present invention. The IPG page 900 of Figure 9 
comprises a first 905A, second 905B and third 905C time slot objects, a plurality of 
channel content objects 910-1 through 910-8, a pair of channel indicator icons 941 A, 
5 94 IB, a video barker 920 (and associated audio barker), a cable system or provider logo 
915, a program description region 950, a day of the week identification object 931, a time 
of day object 939, a next time slot icon 934, a temporal increment/decrement object 932, 
a "favorites" filter object 935, a "movies" filter object 936, a "kids" (i.e., juvenile) 
programming filter icon 937, a "sports" programming filter object 938 and a VOD 
10 programming icon 933. It should be noted that the day of the week object 931 and next 
time slot icon 934 may comprise independent objects (as depicted in Figure 9) or may be 
considered together as parts of a combined object. 

In a system, illustratively, comprising 80 channels of information, the 
channels are displayed in 8-channel groups having associated with them three hour time 

15 slots. In this organization, it is necessary to provide 10 video PIDs to carry the present- 
time channel/time/title information, one or more audio PID to carry the audio barker 
and/or one or more data PID (or other data transport method) to carry the program 
description data, overlay data and the like. To fully broadcast interactive program 
information up to 24 hours in advance, it is necessary to provide 160 (10*24/1.5) video 

20 PIDS, along with one or more audio and, optionally, one or more data PIDs. The amount 
of time provided for in broadcast video PIDs for the given channel groups comprises the 
time depth of the program guide, \yhile the number of channels available through the 
guide (compared to the number of channels in the system) provides the channel depth of 
the program guide. In a system providing only half of the available channels via 

25 broadcast video PIDs, the channel depth is said to be 50%. In a system providing 12 
hours of time slot "look-ahead," the time depth is said to be 12 hours. In a system 
providing 16 hours of time slot "look-ahead" and 4 hours of time slot "look-back," the 
time depth is said to be +16/-4 hours. 

The video streams representing the IPG are carried in a single transport 
30 stream or multiple transport streams, within the form of a single or multi-programs as 
discussed previously in this invention. A user desiring to view the next 1 .5 hour time 
interval (e.g., 9:30 - 1 1 :00) may activate a "scroll right" object (or move the joystick to 
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the right when a program within program grid 902 occupies the final displayed time 
interval). Such activation results in the controller of the STT noting that a new time 
interval is desired. The video stream corresponding to the new time interval is then 
decoded and displayed. If the corresponding video stream is within the same transport 
5 stream (i.e., a new PID), then the stream is immediately decoded and presented. If the 
corresponding video stream is within a different transport stream, then the related 
transport stream is extracted from the broadcast stream and the related video stream is 
decoded and presented. If the corresponding transport stream is within a different 
broadcast stream, then the related broadcast stream is tuned, the corresponding transport 
10 stream is extracted, and the desired video stream is decoded and presented. 

A user interaction resulting in a prior time interval or a different set of 
channels results in the retrieval and presentation of a related video stream. If the related 
video stream is not part of the broadcast video streams, then a pointcast session is 
initiated as described above in relation to Figs. 3A and 3B. For this purpose, the STT 

1 5 sends a request to the head end via the back channel requesting a particular stream. The 
head end then processes the request, retrieves the related stream from the information 
server, incorporates the stream within a transport stream as a video PID (preferably, the 
transport stream currently being tuned/selected by the STT) and informs the STT which 
PID should be received, and from which transport stream it should be demultiplexed. The 

20 STT then retrieves the related video PID. In the case of the video PID being within a 

different transport stream, the STT first demultiplexes the corresponding transport stream 
(possibly tuning a different QAM stream within the forward channel). 

Normally, upon completion of the viewing of the desired stream, the STT 
indicates to the head end that it no longer needs the stream, whereupon the head end tears 

25 down the pointcast session. The viewer is then returned to the broadcast stream from 
which the pointcast session was launched. However, as described above in relation to 
Figs. 6A, 6B, and 6C, the method for "sharing" pointcasts may avoid the need to tear 
down the pointcast session if another STT is still utilizing the pointcast. In addition, the 
above described pointcast sharing technique more efficiently utilizes the network 

30 bandwidth allocated to pointcasts. 
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